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I.  SOFTWARE  REUSE 


A.  INTRODUCTION 

This  thesis  is  part  of  a  larger  study  sponsored  by  the  Director  of  Defense 
Information  (DDI)  in  which  a  series  of  case  studies  are  being  conducted  to  focus  on  the 
sound  practices  of  MIS  implementation  in  DoD.  This  particular  case  study  examines  the 
concept  of  software  reuse  and  focuses  on  the  DoD  Defense  Software  Repository  System 
(DSRS)  initiative.  DSRS  is  a  DoD  version  of  the  Army’s  Reusable  Ada  Products  for 
Information  Systems  Development,  and  their  methodology  for  software  reuse.  It  will 
also  identify  critical  success  factors  in  implementing  a  DoD-wide  policy  on  code  reuse. 

B.  PURPOSE  OF  RESEARCH 

The  DoD  Corporate  Information  Management  (CIM)  initiative  promotes  the  use  of 
Information  Technology  to  improve  business  processes  and  the  management  of 
information  resources.  Software  reuse  has  been  identified  by  the  Office  of  Defense 
Information  as  a  key  strategy  intended  to  help  DoD  respond  to  variable  threats  in  a 
rapidly  changing  environment  with  less  resources.  The  integration  of  software  reuse 
practices  into  lifecycle  development  of  DoD  systems  will  be  a  critical  factor  in  achieving 
significant  reduction  in  the  amount  of  time  required  to  develop  complex  systems. 
Equally  important  is  the  anticipated  increase  in  system  reliability  and  decrease  in  dollars 
spent  for  systems  maintenance  following  implementation.  The  DSRS  goal  is  to  obtain 
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general  purpose,  adaptable  software  components  that  have  maximum  potential  for  reuse. 
They  have  established  procedures  and  guidelines  to  certify  reusable  software  components. 

C.  RESEARCH  METHODOLOGY 

This  thesis  is  a  case  study  that  reviews  recent  literature  on  software  reuse,  conducts 
on  site  field  interviews  with  CIM,  RAPID,  and  DSRS  personnel,  and  derives  lessons 
learned  from  the  RAPID/DSRS  effort  achieved  to  date. 

This  study  focuses  on  the  RAPID/DSRS  effort  and  the  methodology  for  software 
reuse.  RAPID/DSRS  provides  a  comprehensive  and  structured  framework  for  software 
reuse  that  could  be  of  potential  benefit  to  all  users.  Procedures  to  certify  reusable 
software  components  proposed  by  RAPID  will  also  be  discussed. 

D.  RESULTS  OF  RESEARCH 

The  results  of  this  research,  and  all  references  are  contained  in  the  Appendix. 
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I.  Executive  Summary 


To  be  successful  in  meeting  the  strategic  challenges  of  today’s  rapidly  changing 
world,  Information  Technology  managers  must  become  proficient  at  doing  more  with 
less.  Information  has  become  a  strategic  resource  for  many  organizations.  To  manage 
it,  development  activities  are  asked  to  deliver  more  software,  more  quickly  and  with 
lower  fault  tolerances  than  ever  before.  As  the  demand  for  new  software  steadily 
increases,  so  does  the  demand  for  supporting  assets  to  maintain  the  system.  In  this 
environment  of  fiscal  austerity,  Program  Managers  are  facing  these  accelerating 
requirements  with  budgets  that  remain  stagnant  or  even  dwindle  from  year  to  year. 

Software  reuse  can  make  a  substantial  contribution  towards  an  organization’s 
efficiency  and  effectiveness  in  satisfying  these  requirements.  Experts  estimate  that  as 
much  as  half  the  code  written  for  information  systems  is  reusable  in  other  development 
efforts.  In  the  Department  of  Defense  (DoD),  where  expenditures  for  administrative 
systems  will  approach  5  billion  dollars  this  year,  the  potential  savings  generated  through 
a  comprehensive  reuse  program  are  staggering. 

The  Army  recognized  the  potential  for  returns  on  an  investment  in  reuse  and 
initiated  the  Reusable  Ada  Products  for  Information  System  Development  (RAPID) 
program  in  1987.  Their  approach  centered  on  a  library  of  reusable  software  components 
made  available  to  software  development  teams.  Software  modules  that  satisfactorily 
completed  a  quality  review  were  categorized  and  loaded  to  the  repository.  Users  could 
then  browse  library  assets  selecting  those  modules  that  satisfied  new  development 
requirements. 

RAPID’s  most  significantly  contributed  to  the  reuse  effort  by  establishing  an 
infrastructure  (i.e.  the  repository  framework,  cataloging  systems  retrieval  systems,  etc.), 
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for  implementing  a  reuse  methodology.  DoD,  committed  to  the  concept  of  reuse  and  its 
potential  savings  adopted  the  RAPID  Program  as  its  own  and  established  the  Defense 
Software  Repository  System  (DSRS)  in  1991.  The  DSRS  now  supports  users  in  all 
branches  of  the  service  providing  a  repository  for  contributions  and  distribution  of 
software  components. 

Though  the  application  of  a  reuse  technology  in  DoD  is  still  in  its  early  stages  of 
growth,  the  experience  of  both  RAPED  and  the  DSRS  provide  some  valuable  insights: 


The  concept  of  a  central  clearinghouse  to  process  the  intake  and  distribution  of 
software  is  critical  to  the  success  of  a  DoD-wide  initiative. 

Use  of  such  a  clearinghouse  can  provide  substantial  increases  in  development 
productivity. 

To  enhance  user  confidence  and  the  perpetuation  of  the  reuse  approach, 
repository  supervisors  must  ensure  only  quality  components  are  admitted  to  the 
library. 

Utilization  of  the  clearinghouse  could  be  significantly  enhanced  through 
the  introduction  of  a  DoD-wide  incentive  program. 
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n.  Software  Reuse:  Doing  More  With  Less 


Reuse  of  prior  work  is  certainly  not  a  new  concept.  When  electrical  engineers 
set  out  to  develop  a  new  circuit  board,  they  often  reuse  pre-fabricated  integrated  circuits, 
made  available  to  them  through  technical  catalogs,  to  accelerate  the  development  process. 
Likewise,  corporate  executives  rely  heavily  on  standard  text  documents  to  prepare  legal 
and  business  documents.  In  the  software  environment,  with  billions  of  lines  of  codes  and 
thousands  of  implemented  information  systems,  existing  software  modules  could  be 
recycled  to  avoid  the  exorbitant  costs  of  "re-inventing  the  wheel". 

Software  reuse  can  be  defined  as  the  application  of  one  or  more  previously 
developed  software  component(s)  to  a  new  system  or  to  an  expansion  of  an  existing 
system.  Often  times,  a  significant  portion  of  almost  any  new  program  contains  logic  that 
essentially  duplicates  the  code  found  in  other  programs.  Software  developers  for  large 
organizations  are  just  beginning  to  appreciate  the  potential  benefits  of  reuse  and  are  now 
seriously  integrating  reuse  practices  into  the  software  development  process. 


A.  Beyond  Code  Reuse 

To  date,  efforts  to  reuse  software  have  been  primarily  focused  at  the  code  level. 
Code  reuse  is  the  simplest  form  of  reuse.  A  reusable  code  component  consists  of 
functions,  procedures,  or  packages.  Once  developed,  this  component  is  tested,  certified, 
and  stored  in  a  repository  so  that  it  can  be  accessed  by  programmers  for  new  software 
development  projects. 

Savings  associated  with  code  reuse  can  be  realized  in  two  ways:  (a)  each  time 
a  portion  of  code  is  reused,  resources  otherwise  devoted  to  coding  can  be  saved;  (b) 


3 


further  savings  are  also  realized  in  the  testing  phase.  In  general,  the  "payoff"  for  reusing 
a  chunk  of  code  is  directly  proportional  to  the  size  of  the  chunk. 


As  the  size  of  the  code  segment  increases,  it  becomes  more  difficult  for  the 
programmer  to  identify  a  good  match  with  specified  functions.  A  large  segment  of  code 
usually  offers  many  functionalities.  However,  the  greater  the  functionalities  embodied 
in  the  new  segment,  the  more  difficult  it  is  for  the  developer  to  succinctly  describe  the 
functional  specifications  of  that  segment.  Larger  components  also  tend  to  be  more 
specialized  or  idiosyncratic  and  are  therefore  less  likely  to  be  compatible  with  a  given 
set  of  requirements  specifications. 

Reuse  at  the  analysis  and  design  level  implies  that  the  developer  must  ignore 
coding  details,  and  focus  on  the  computational  intent  of  larger  chunks  of  code  that 
compose  the  system.  Instead  of  looking  at  the  coding  style  (e.g. ,  the  date/calendar  code 
segment),  the  developer  should  examine  how  functional  structures  and  specifications 
(i.e. ,  date  and  calendar  functions)  are  used  in  the  .context  of  the  application.  Reusable 
components  at  higher  levels  include  logical  data  models,  functional  descriptions  and 
diagrams  (e.g.,  data  flow  diagrams  or  entity  relationship  diagrams).1  Although 
component  reuse  at  the  code  level  is  better  understood  and  by  far  the  most  prevalent 
form  of  reuse  at  other  levels,  one  can  witness  an  acceleration  in  the  reuse  of  the  other 
types  of  software  components. 

For  a  given  organization,  there  tends  to  be  a  family  of  application  software  that 
shares  some  common  design  characteristics.  If  these  similar  software  design  components 
could  be  reused,  the  developer  would  be  free  to  concentrate  on  implementation  of  the 
unique  functionalities  of  the  software.  Since  design  does  not  yet  contain  detailed 
decisions  for  implementation,  a  component’s  potential  for  reuse  is  greater.2  Reusable 
design  should  provide  pointers  to  the  appropriate  pieces  of  reusable  code,  reusable  test 


1  Neider,  1987 

2  Lenz,  1987 
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cases,  and  documentation.  As  a  result,  design  reusability  tends  to  provide  much  higher 
leverage  than  simply  reusing  code.3 

Technically,  existing  software  can  be  reused  in  a  variety  of  ways.  The  spectrum 
includes  sharing  of  code,  algorithms,  routines  in  application  families,  and  subsystems.4 
Reuse  can  be  applied  to  all  phases  of  the  software  development  life-cycle,  including: 

•  Requirements  specifications 

•  High-level  design 

•  Detailed  design 

•  Coding  and  unit  testing 

•  Integrating  testing 

•  Documentation 

•  Maintenance 


B.  Desirable  Characteristics  of  a  Reusable  Software  Component 

Reusable  Software  Components  (RSCs)  can  be  extracted  from  public  domain 
software,  commercial  off-the-shelf  software,  contractors,  and  government  sources.  A 
desirable  reusable  software  component  should  include  the  following  characteristics: 

•  Flexibility-.  The  developer  should  be  able  to  adapt/modify  the  RSCs  to  fit  in  with 
the  overall  architecture  of  the  software  to  be  built.  The  smaller  the  component 
in  terms  of  functionality,  the  more  flexible  it  is  but  the  less  functionality  it 
provides. 

•  Expandability :  The  developer  should  be  able  to  tailor  RSCs  to  specific 
requirements  that  might  surface  well  after  initial  requirements  were  defined. 


3  Biggerstaff  and  Lubars,  1991 

4  Lenz,  1987 
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Portability :  The  RSCs  should  be  able  to  operate  under  multiple  operating 
environments  (physical  hardware,  operating  systems,  and  runtime  environments) 

Language  Independence:  The  components  above  the  implementation  level  should 
be  programming  language  independent  so  that  they  are  reusable  in  any 
programming  language  environment. 


C.  Productivity  Gains  with  Reuse 

Software  reuse  provides  a  number  of  benefits.  Reusing  software  should  help  the 

information  systems  developer: 

•  Improve  software  development  productivity:  Software  reusability  is  viewed  widely 
as  a  major  opportunity  for  improving  software  productivity.5  At  industry’s 
present  rate  of  growth,  a  20%  improvement  in  productivity  is  projected  to  result 
in  a  savings  of  $45  billion  in  1995  for  the  U.S.  alone.6 

•  Achieve  shorter  development  time:  When  a  developer  is  able  to  reuse  previously 
generated  software  in  a  new  application,  he/she  frees  up  assets  that  can  be 
devoted  instead  to  development  of  the  system’s  unique  modules.  The  savings  in 
time  and  resources  translates  to  a  development  environment  that  is  more 
responsive  to  the  requirements  of  a  dynamic  world. 

•  Increase  software  reliability:  Preexisting  software,  if  it  has  been  employed  to  any 
extent,  has  already  been  field  tested  and  fine  tuned.  This  offers  the  opportunity 
of  deploying  modules  whose  expected  error  rate  is  significantly  lower  than  that 
of  a  newly  developed  module. 

•  Ensure  enhanced  maintainability:  Reuse  of  well-structured  and  well-documented 
software  will  also  lead  to  improved  maintainability  and  portability  in  that 
alterations  will  be  required  only  on  the  source  component  located  in  the  central 
repository.  With  studies  indicating  a  significant  number  of  companies  spending 
between  60  and  80  percent  of  their  software  dollars  on  maintenance, 7  this  area 
may  well  generate  the  most  significant  dollar  savings. 


5  Biggerstaff  and  Richer,  1987 

•  Boehm,  1987 

7  Biggerstaff  and  Lubars,  1991 
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Software  reusability  is  now  recognized  as  a  major  opportunity  for  improving 
software  productivity.  Software  costs  were  estimated  in  1990  to  be  $125  billion  for  the 
U.S.  alone.  With  such  a  magnitude  in  software  costs,  even  a  modest  improvement 
thourgh  reuse  can  translate  into  tremendous  savings. 
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HI.  A  Clearinghouse  for  Software  Reuse 


A.  Toward  the  Concept  of  a  Clearinghouse  for  Reuse 

To  effectively  reuse  software,  RSC  donors  and  recipients  must  incur  non-trivial 
technical  and  administrative  overheads.  They  need  a  central  organization,  say,  a 
clearinghouse,  to  relieve  them  of  these  overhead  costs.  It  is  through  the  clearinghouse 
that  the  interactions  between  the  users  and  donors  can  be  assured. 


1 .  The  RSC  Donor-Recipient  Cycle 

In  many  instances,  an  RSC  will  come  from  existing  systems  or  systems  currently 
under  development.  For  an  RSC  to  be  reusable  beyond  its  development  site,  it  is 
important  to  distinguish  the  point  of  view  of  the  donor  from  that  of  the  recipient.  A 
donor  is  one  who  identifies  reusability  of  an  RSC,  develops  the  RSC  that  satisfies 
reusability  specifications,  and  makes  the  RSC  available  in  a  library  or  repository.  A 
recipient  is  a  developer  who  reviews  RSC  available  in  the  library  and  selects  those  that 
most  closely  support  his  requirements.  Mechanisms  for  implementation  as  well  as  issues 
involving  incentives  or  technical  problems,  for  example,  will  vary  depending  on  the 
orientation  as  donor  or  recipient. 


a.  Mechanism  for  Creating  RSCs  —  the  Donor's  Perspective 

When  a  program  manager  participates  in  the  process  of  contributing  software,  he 
assumes  a  donor’s  perspective  to  reuse.  He  needs  to  identify  and  describe  the 
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functionalities  embedded  in  candidate  RSCs.  He  also  needs  to  carry  out  testing  and 
documentation  for  those  RSCs. 

A  willing  donor  is  one  who  is  able  to  look  beyond  the  immediate  costs  both  in 
time  and  resources  and  commit  to  the  long-range  reuse  strategy.  To  alleviate  this  effort, 
help  from  external  source(s)  is  usually  required  unless  the  donor  himself  is  in  the 
business  of  software  production  and  can  reap  the  benefits  of  donated  RSCs. 


b.  Mechanism  for  Retrieving  and  Using  an  RSC  —  the  User’s  Perspective 

In  contrast  to  the  donor’s  orientation  where  benefits  from  reuse  are  anticipated  at 
some  point  in  the  future,  RSC  users  realize  an  immediate  advantage.  To  maximize  the 
benefits  of  reuse,  the  user  must  possess  skills  and  experience  to: 

•  Find  RSCs  (cataloging,  search  and  retrieval  mechanisms) 

•  Understand  RSCs’  characteristics 

•  Adapt  RSCs  to  his  functional  requirements 

From  the  user’s  perspective,  reuse  will  be  attractive  only  if  the  overall  effort  to 
reuse  a  piece  of  software  is  less  than  the  effort  required  to  create  it  from  scratch.  If  a 
user  has  to  invest  an  unacceptable  amount  of  time  in  searching  and  evaluating  repository 
components,  he  will  likely  opt  to  develop  the  component  himself  instead.  Thus,  it  is 
critical  that  an  RSC  library  be  made  available  to  the  users.  This  repository  has  to 
contain  RSCs  that  correspond  to  the  user’s  requirements  and  needs. 


2.  Motivations  for  a  Clearinghouse 

As  discussed  in  the  previous  section,  reuse  is  an  appealing  concept  but  its 
implementation  requires  a  sustained  economic  and  managerial  effort  that  goes  beyond  that 
of  an  individual  participating  software  developers.  The  creation  of  a  clearinghouse  for 
reuse  is  required  to  assume  and  direct  much  of  this  effort,  provide  broader  visibility  of 
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useful  software,  promote  standardization,  and  yield  greater  savings  of  maintenance 
dollars. 


a.  Economic  Incentive 

Before  software  reuse  can  begin  to  pay  off,  an  up-front  investment  is  required. 
There  will  generally  be  costs  involved  in  the  preparation  of  the  software  prior  to  its 
induction  into  the  library.  Whether  software  is  written  for  future  reuse  or  taken  from 
somewhere  else,  it  requires  formatting,  testing,  and  documentation.  Providing  untested 
and  undocumented  RSCs  is  counterproductive.  If  the  user  needs  to  perform  significant 
modifications  to  adapt  the  component,  the  benefit  of  reuse  may  be  lost. 

In  the  short  run,  management  of  organizations  that  desire  to  donate  software 
cannot  be  expected  to  support  up-front  costs  for  making  RSCs.  The  fear  that  reusability 
will  lead  to  reduction  in  their  budget  and  staff  is  also  a  source  of  resistance  among 
managers  and  programmers.*  Programmers  are  often  penalized  for  taking  the  extra  time 
to  make  software  reusable. 

It  is  thus  important  that  a  clearinghouse  for  reuse  be  built  to  absorb  the  cost  of 
establishing  RSCs  and  —  more  importantly  —  maintaining  a  library  of  reusable  software 
components.  The  cost  of  a  library  depends  on  its  size  and  the  tools  used  to  populate, 
organize,  access,  and  maintain  RSCs. 

A  clearinghouse  for  reusable  software  has  significant  advantages.  With  its 
resources  dedicated  to  reuse,  the  clearinghouse  can  assume  the  essential  and  unique  role 
of  networking  multiple  libraries  owned  by  various  participating  organizations  developing 
similar  software,  thus  yielding  economies  of  scale.  It  can  also  develop  its  own  RSCs  if 
they  cannot  be  found  anywhere  else.  The  economics  of  software  reuse  vary  significantly 
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'  Wong,  1987 
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with  the  problem  domain  and  the  development  technology  employed  within  an 
organization.9 

It  is  expected  that  the  cost  savings  of  reusing  thoroughly  tested  and  documented 
software  will  be  even  more  significant  in  the  long-run.  However,  the  long-term  benefits 
of  reuse  are  often  hampered  by  short-sightedness  of  many  RSC  donors  and  users.  It  is 
the  mission  of  the  clearinghouse  to  correct  this  short-term  perspective,  and  play  an  active 
role  in  reconciling  conflicting  interests  between  individual  RSC  donors  and  recipients. 10 


b.  Managerial  Incentive 

Researchers  tend  to  agree  that  the  lack  of  a  clear  reuse  strategy  has  been  one  of 
the  major  factors  inhibiting  widespread  software  reusability."  The  absence  of  an 
appropriate  high-level  reuse  strategy  results  in  project  managers  and  programmers  being 
unmotivated  to  reuse  software.  Reuse  will  not  happen  by  itself:  it  needs  to  be  promoted 
with  incentives. 

Top  management  of  participating  organizations  must  understand  management's 
critical  role  in  addressing  non-technical  issues  such  as  legal  and  proprietary  rights, 
compensation  for  RSC  developers,  and  internal  cost  apportionment  methods  for 
purchasing  reusable  components  associated  with  software  reuse.12  Contract  issues 
concerning  ownership  and  rights  to  the  developed  software  arise.  Contracts  must  be 


9  Barnes,  1987 

10  Who  pays  the  added  development  cost  involved  in  designing  the  software  for  reuse?  Ideally,  the 
organization  that  profits  from  the  reuse  should  pay  for  it,  but  it  does  not  always  work  this  way.  For 
example,  a  contractor  might  be  asked  to  make  his  software  reusable  with  little  recognition  of  the  added 
cost  required.  As  a  consequence,  he  earns  a  lower  profit.  Furthermore,  the  software  component  could 
then  be  given  to  a  competitor  to  be  reused,  thus  allowing  the  competitor  to  capitalize  on  the  initial 
contractor’s  efforts.  It  can  work  in  the  contractor’s  favor  as  well:  the  customer  might  pay  an  added  cost 
for  highly  reusable  software  without  realizing  it,  so  that  the  contractor  can  reuse  the  software  in  his  own 
future  programs. 

"  Biggerstaff  and  Richer,  1987 

12  Banker  and  Kaufman,  1990 
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tailored  to  meet  the  needs  of  both  donors  and  users  in  order  to  provide  an  incentive  for 
reuse. 

Management  that  invests  in  the  development  of  a  meaningful  incentives  program 
will  enhance  their  organization’s  chances  of  implementing  a  successful  reuse 
environment.  For  example,  the  National  Aeronautics  and  Space  Administration  (NASA), 
in  a  move  to  encourage  development  of  higher  quality  software  by  contractors,  has 
instituted  financial  rewards  for  certain  types  of  library  resident  routines.  Developers  are 
compensated  forextracting  software  from  the  library  instead  of  being  paid  solely  by  the 
quantity  of  new  code  they  create.  This  provides  the  contractor  with  incentive  to  utilize 
the  methodologies  of  reusable  code.13 

GTE  provides  another  example.  GTE  Data  Services  places  major  emphasis  on 
incentives  and  has  introduced  a  program  that  rewards  authors,  project  managers,  and 
reusers.  Programmers  receive  both  cash  bonuses  (when  an  asset  was  accepted  into  the 
repository)  and  royalties  each  time  an  asset  is  reused  in  a  new  application.  Budget 
increases  and  promotions  for  project  managers  are  directly  linked  to  high  percentage 
reuse  in  deliverables  under  their  cognizance.  GTE  considers  the  incentive  program  a  key 
factor  in  their  reuse  success  which  translates  into  an  estimated  savings  of  $1.5  million 
during  the  program’s  first  year  of  operation  and  a  projection  of  $10  million  by  the  end 
of  the  fifth  year.14 


B.  Activities  of  the  Clearinghouse 

The  following  are  the  main  activities  that  the  clearinghouse  should  perform  on 
behalf  on  the  reuse  community: 


13  Cashin,  1991 

14  Prieto-Diaz,  1987 
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1 .  Defining  Reusable  Domains 


Since  software  comes  from  a  variety  of  domains,  there  is  a  need  to  identify 
software  components  that  share  basic  functionalities.  This  can  be  achieved  by  a  process 
known  as  domain  analysis.  The  purpose  of  domain  analysis  is  to  determine 
commonalities  within  the  application  domain,  focusing  on  areas  with  the  greatest  potential 
for  reuse  and  in  greatest  demand  by  future  software  developers.  It  is  an  iterative  process 
involving  an  intense  examination  of  the  domain  of  interest.15  Without  a  well-performed 
domain  analysis,  RSCs  cannot  properly  be  identified. 


2.  Searching  for  RSCs 

The  search  for  RSCs  is  a  non-trivial  effort.  Potential  sources  (e.g.,  existing 
governmental  systems,  public  domain  software,  or  commercial  off-the-shelf  software) 
have  to  be  identified.  Of  particular  concern  during  this  component  search  is  a  donor’s 
reputation  or  track  record  for  producing  quality  software. 


3.  Certifying  RSCs 

Certification  refers  to  the  process  designed  to  solve  and  eliminate  concerns 
programmers  and  managers  have  about  using  RSCs  that  originate  from  outside  their  own 
work.  Such  concerns  include  quality,  maintainability,  liability  for  defects,  and 
testability.  A  certified  RSC  must  function  as  it  is  intended  to  function.  Evaluation  is  a 
very  important  part  of  the  certification  process.  It  begins  as  candidate  RSCs  are 
identified  and  continues  through  the  remainder  of  the  life  cycle.  Evaluation  can  eliminate 


15  Softech,  RAPID  Center  Reusable  Software  Component  Procedures,  June  1990 
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unsatisfactory  components,  identify  re-engineering  needs,  produce  documentation,  and 
initiate  essential  metrics.16 


4.  Creating  a  User-Friendly  Library 

A  library  system  is  needed  for  users  to  identify,  retrieve,  and  use  RSCs. 
Software  selected  for  incorporation  in  the  library  must  be  integrated  with  other  repository 
components  via  an  identification  scheme.  The  cataloging  system  implemented  should  be 
easy  for  the  user  to  understand,  and  should  provide  alternative  search  patterns  for  the 
user  to  search  for  the  perfect  component.  Lastly,  the  indexing  system  should  be 
adaptable  in  the  event  that  future  components  are  not  easily  tailored  to  existing 
categories. 


5.  Supporting  RSC  Users 

A  productive  reuse  environment  cannot  be  maintained  without  the  confidence  of 
the  user.  This  confidence  is  achieved  in  several  ways.  Most  notably,  the  RSC 
certification  process  contributes  to  this  effort  by  ensuring  both  the  quality  and 
standardization  of  each  component  in  the  repository.  Additionally,  RSC  users’  concerns 
and  needs  should  be  periodically  surveyed  to  ensure  efforts  are  continually  focused  on 
the  needs  of  the  customer. 


In  summary,  the  implementation  of  a  clearinghouse  offers  several  advantages: 

The  clearinghouse  can  perform  domain  analysis  over  a  broad  range  of 
applications,  that  will  likely  increase  the  accuracy  of  the  domain  model  and  its 
relevance  for  future  application  development. 


16  Metrics  assist  managers  in  measuring  various  things  and  allow  engineers  to  apply  predictive 
algorithms.  Metrics  include  size,  productivity,  efficiency,  and  quality  characteristics  such  as  portability, 
maintainability,  and  reusability.  Metrics  also  provide  a  prediction  of  problem  areas  and  alternative 
solutions. 
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With  its  central  position,  the  clearinghouse  has  the  authority  and  expertise  to 
enforce  a  strict  reuse  discipline.  Certification  procedures  can  be  put  in  place  to 
ensure  uniform  quality  of  RSCs.  This  directly  influences  user  confidence  in  the 
clearinghouse. 

As  the  clearinghouse  imposes  a  standardized  reuse  procedure,  it  offers  the 
opportunity  to  serve  a  larger  community. 
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IV.  DSRS  -  A  Clearinghouse  for  Software  Reuse 


A.CIM  and  Reuse 

Launched  in  October  1989,  the  DoD  Corporate  Information  Management  (CIM)  initiative 
seeks  to  improve  DoD  business  processes  and  the  management  of  information  resources. 
To  achieve  this  goal,  CIM  is  calling  for  functional  interoperability  between  systems, 
standards  compliance,  and  efficiency  in  software  development  through  reliance  on 
reusable  software  components,  commercial  off-the-shelf  products,  and  computerized 
application  development  aids. 

CIM  promotes  two  types  of  repositories:  software  reuse  repository  and  hardware  reuse 
repository.17  The  objectives  of  software  reuse  repository  are  to: 

•Develop  a  central  DoD-wide  RSC  clearinghouse 

•Establish  a  data  dictionary  for  DoD 

•Build  an  integrated  repository  for  C3I  software 

On  the  other  hand,  the  hardware  reuse  repository  seeks  to: 

•Shorten  acquisition  cycle  by  leasing 

•Introduce  a  standard  bus  architecture  for  scalable  processors 

•Provide  for  central  technology  renovation 

•Rationalize  capacity  and  security  management  practices 

•Distribute  capacity  by  means  of  survivable  networks 

Software  reuse  is  considered  to  be  one  of  the  key  strategies  intended  to  help  DoD  in 
responding  to  variable  threats  in  a  rapidly  changing  environment  with  less  resources. 


17  Strassman,  1991 
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The  Office  of  the  Director  of  Defense  Information  set  the  following  goals  for  software 
reuse: !* 

•  100%  reusable  data  with  an  infinite  life  for  data  definitions 

•  More  than  80%  reusable  code  with  more  than  20  year  life  on  software  elements 

•  80/20  development/maintenance  ratio 

•  Technology  asset  life  two  to  three  times  larger  than  the  technology  innovation 
cycle. 

The  goal  of  implementing  a  DoD-wide  repository  of  reusable  components  has 
culminated  in  the  recent  establishment  of  the  Defense  Software  Repository  Service 
(DSRS).  Under  the  administration  of  the  Center  for  Software  Reuse  Operations 
(CSRO),19  the  DSRS  provides  automated  access  to  more  than  1550  government  or 
commercially  owned/developed  RSCs.  This  repository  is  available  to  all  DoD,  other 
government  agencies,  and  authorized  contractors. 

The  design  and  implementation  of  DSRS  is  based  on  a  pilot  operation  initiated  by 
the  Army’s  Reusable  Ada  Product  for  Information  System  Development  (RAPID).  This 
chapter  reports  some  of  the  experiences  gained  by  RAPID,  and  subsequently  DSRS. 


B.  RAPID  -  The  Army’s  Software  Broker 
1 .  History  and  Mission 

The  Army  recognized  the  tremendous  potential  of  software  reuse.  It  called  for  the 
establishment  of  a  software  reuse  clearinghouse  offering  Army/DoD  users  a  centralized 
repository  of  reuse  components  by  initiating  the  RAPID  project  in  1987.20 


11  Strassman,  1991 

19  CSRO  has  been  set  up  within  the  Defense  Information  System  Agency’s  Center  for  Information 
Management. 

20  RAPID  was  located  at  the  U.S.  Army  Information  Systems  Software  Development  Center, 
Washington  (SDC-W). 
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With  Ada  as  the  programming  language  mandated  by  Congress,  RAPID  sought 
to  promote  the  reuse  of  Ada  software  to  reduce  the  cost  of  system  development  and 
maintenance  through  the  use  of  previously  developed  tested  and  implemented 
components.  Ada  is  a  programming  language  designed  to  facilitate  reusability  because 
its  reusability  guidelines  are  structured  to  include  design  for  reuse,  parameterization,  and 
domain  analysis.21  Ada  code  is  portable  in  that  code  written  anywhere  is  potentially 
reusable  for  another  system.  It  is  well  suited  to  the  integration  of  system  components 
from  multiple  sources. 

RAPID  defines  its  missions  as  follows: 

•  Achieve  the  Department  of  Defense  (DoD)  initiative  of  reusable,  maintainable, 
and  reliable  software 

•  Develop,  maintain,  and  administer  a  comprehensive  reuse  program 

•  Lower  software  lifecycle  costs  by  increasing  productivity  and  quality. 

Initially  intended  for  management  information  systems  (e.g.,  financial,  logistics, 
and  personnel  systems  applications),  RAPED  expanded  its  domain  to  additional 
application  areas  (e.g.,  telecommunications).  In  1991,  it  had  more  than  960  reusable 
components  stored  in  a  central  repository  available  to  all  Army/DoD  units.  RAPID 
would  then  issue  software  to  both  DoD  users  and  contractors  working  on  DoD  projects 
as  government-furnished  equipment  (GFE). 


2.  RAPID  Implementation  Plan 

RAPED  was  initiated  at  SDC-W  as  a  pilot  prototype  reuse  program  in  July  1987 
when  the  Phase  I  contract  was  awarded.  This  initial  phase  produced  the  foundation 
needed  to  provide  a  reusability  program  within  SDC-W.  Table  1  depicts  the  chronology 
of  the  phases  of  the  RAPID  project. 


21  Banker  and  Kaufman,  1990 
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RAPID  PROJECT  PHASES  I 

PHASE  I:  Design  and  Development  (July  1987  -  April  1989)  1 

• 

RAPID  Center  Concepts  and  Organization 

• 

Reuse  Policies  and  Procedures 

• 

RAPID  Center  Library  System 

PHASE  II:  Pilot  Operation  (May  1989  -  December  1990)  1 

• 

• 

• 

• 

• 

• 

Operate  Active  RAPID  Center 

Support  SAC-W  Customers 

Policy  and  Procedure  Refinement 

Library  Population 

Training  Program 

Domain  Analysis 

PHASE  HI:  Implementation  (January  1991  -  September  1991)  1 

• 

Expand  to  all  ISEC  Development  Centers 

• 

Expand  to  Other  Organizations 

• 

Continue  Library  Population  and  Enhancements 

PHASE  IV:  CIM  Operation  (October  1991  -  October  1996)  1 

• 

Individual  Service  focused  Support 

• 

Expand  Domain  Analysis  Customers 

• 

Continue  Library  Population 

3.  RAPID  Staff  Organization 

Under  the  supervision  of  a  center  manager,  the  RAPID  staff  is  composed  of 
technical  consultants,  systems  analysts,  software  engineers,  configuration  management 
specialists,  quality  assurance  personnel,  administrative  assistants,  and  librarians.  The 
staffs  mission  is  to  encourage  design  methods  and  architectures  that  build  from  reusable 
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components.  Systems  analysts  and  software  engineers  provide  vital  support  for  RAPID’s 
role  as  a  software  clearinghouse  while  other  positions,  such  as  RAPID’s  administrative 
assistants,  are  more  heavily  weighted  towards  user  assistance  or  RSC  cultivation. 

Support  personnel  for  the  program  consisted  of  16  government  employees  and  8 
contractor  personnel.  The  following  describes  some  specific  positions  of  these  staff 
members: 

a.  The  RAPID  Manager.  Continually  monitors  the  success  of  the  RAPID  program 
and  the  results  of  specific  operations.  He  keeps  extensive  reports  that  help  evaluate  the 
costs  of  the  program  as  well  as  the  savings  to  developers. 

b.  Technical  Consultants :  Perform  the  domain  analysis,  attend  design  reviews,  stay 
abreast  of  projects,  advise  project  staffs,  and  assist  the  developer  in  identifying  potential 
areas  of  reuse.  They  help  search  for  RSCs,  and  provide  guidance,  support,  and 
documentation  to  programmers. 

c.  System  Analysts  and  Software  Engineers :  Identify  high-value  RSCs  that  are  to  be 
added  to  the  library.  They  evaluate,  test,  and  document  all  RSCs  before  being  added  to 
the  library.  They  also  provide  maintenance  and  enhancements  to  the  RCL  (Rapid  Center 
Library)  software  system. 

d.  Configuration  Management  Specialists:  Ensure  that  all  configuration  activities  are 
performed  for  each  library  component,  including  problem  report  tracking,  controlling 
changes,  and  releasing  new  versions  or  enhancements. 

e.  Quality  Assurance  Specialists :  Ensure  that  all  RSCs  are  of  high  quality  through 
frequent  reviews.  They  develop  and  administer  testing  as  well  as  establish  and  enforce 
metrics. 

f  Administrative  Assistants :  Prepare  all  RAPID  Center  Library  System  reports  and 

perform  follow-up  interviews  with  the  users. 

g.  The  Librarian:  Maintains  the  RSC  data  base  and  performs  normal  operator 
functions. 
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4.  RAPID  Activities  as  a  Clearinghouse 

a.  Defining  Reusable  Domains 

For  a  clearinghouse  to  operate  effectively,  domain  analysis  must  be  performed. 
As  a  continuing  process,  it  not  only  identifies  components  that  may  be  reused,  but  also 
directs  developers  to  areas  where  reuse  emphasis  should  be  placed  so  that  new 
components  can  be  found  during  post-deployment  support. 

As  part  of  the  initial  steps  to  establish  RAPID,  a  high-level  domain  analysis  was 
done  in  1987  that  covered  management  information  systems.  During  the  pilot  operation, 
RAPID  realized  the  need  to  support  multiple  domains.  Therefore,  policies,  procedures, 
and  guidelines  were  revised  to  extend  their  potential  applicability  beyond  MIS. 

Object-oriented  methods  were  adopted  for  domain  analysis.  As  a  standardized 
method,  they  proved  to  be  effective  in  identifying  reuse  opportunities,  and  for  grouping 
RSCs  according  to  the  level  of  abstraction  or  functional  category. 


b.  Searching  for  RSC  Donors 

Once  the  reusable  types  of  software  components  are  identified  through  domain 
analysis,  it  must  be  determined  where  those  components  will  come  from.  This  is  a 
responsibility  of  the  RAPID  engineers.  These  personnel  would  turn  to  a  variety  of 
sources  to  identify  potential  candidates  including: 

»  COTS  Software 

•  Government-owned  Software 

•  Public  Domain  Software 

Of  the  960  RSCs  currently  in  the  repository,  more  than  780  have  been  developed 
commercially.  Of  the  170  government  owned  components,  less  than  30  were  developed 
by  the  RAPID  in-house  engineers. 
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COTS  software  tends  to  be  a  more  appealing  source  for  several  reasons.  It  is 
well-tested  before  release,  and  is  often  accompanied  by  substantial  documentation. 
Typically,  the  software  has  been  in  use  for  a  substantial  period  of  time  before  it  is 
identified  as  a  candidate  RSC.  It  is  thus  likely  to  be  highly  reliable. 

Roughly  85%  of  the  RSCs  in  the  Army  repository  are  code.  The  remaining 
component  types  include  such  software  as  design  components,  documentation 
components,  and  functional  specifications.  Although  originally  conceived  to  house  Ada 
code,  the  repository  does  contain  RSCs  written  in  other  languages  such  as  COBOL,  C 
and  FORTRAN. 


c.  Certifying  RSCs 

The  certification  process  begins  with  a  quality  evaluation  of  the  candidate  RSC 
once  it  is  identified.  The  evaluation  process  not  only  determines  basic  attributes  such  as 
the  lines  of  code  or  number  of  packages  but  also  estimates  the  reuse  potential  for  the 
component.  It  also  estimates  the  level  of  re-engineering  needed  to  ensure  quality 
standard. 

The  certification  includes  testing  on  a  variety  of  platforms.  Re-engineering  is  not 
done  for  commercial  off-the-shelf  components  whenever  code  changes  may  invalidate  the 
license.  COTS  RSCs  are  entered  into  the  RAPID  Center  library  after  the  applicable 
RAPID  Center  documentation  standards  are  met. 

The  RAPID  Center  assigns  a  certification  level  as  "the  level  of  confidence"  in  the 
quality  of  the  RSC;  it  ranges  from  level  I  to  level  V,  as  described  below: 

Level  I:  Depository  -  No  formal  testing  and  documentation 

Level  II:  Reviewed  -  Some  testing  and  documentation 

Level  m:  Tested  -  Test  Suites  Validated  and  some  documentation 

Level  IV:  Documented  •  Fully  tested  and  documented;  meets  all  standards  and 

guidelines 


23 


Level  V: 


Secure  -  Currently  not  used 


Level  V  certification  is  reserved  for  future  use  to  cover  secure  components  in 
accordance  with  DoD  CSC-STD-001-83,  Trusted  Computer  System  Evaluation  Criteria. 
Policies  and  procedures  for  secure  components  will  be  developed  whenever  such  RSC 
become  available. 

Ideally,  every  component  in  the  library  would  be  tested  and  documented  to  the 
extent  that  a  Level  IV  certification  could  be  assigned.  This  has  not  been  the  case 
however,  and  a  significant  number  of  RSCs  were  accepted  into  the  library  at  the  lower 
certification  levels.  Of  the  more  than  780  COTS  components  in  the  repository,  only  285 
were  certified  at  Level  n,  while  the  remaining  components  (COTS)  were  at  Level  IV. 
A  similar  breakout  of  government-owned  components  could  not  be  obtained,  but  it  was 
confirmed  that  a  number  of  these  components  were  certified  at  Levels  I  and  n. 


d.  Creating  a  User-Friendly  Library 

RAPID  uses  a  flexible  faceted  classification  scheme  to  store  and  retrieve  RSCs. 
Using  the  PC-based,  menu-driven  system,  the  user  could  initiate  a  search  for  an  RSC  by 
entering  parameters  or  "facets"  that  describe  the  RSC.  The  nine  facet  classification 
descriptors  listed  below,  allow  the  user  substantial  control  over  the  repository  search: 

•  Component  Type 

•  Language 

•  Unit  Type 

•  Function 

•  Algorithm 

•  Environment 

•  Object 

•  Data  Representation 
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Certification  Level 


To  conduct  a  search,  the  Function,  Language  and  Certification  Level  descriptors 
must  be  provided.  The  use  of  the  other  facet  terms  is  optional.  To  enhance  the  search 
capability,  the  RAPID  search  mechanism  also  provided  the  user  with  a  "thesaurus  list" 
that  helps  identify  facet  terms  (known  as  "synonym  terms")  that  appeared  to  be 
comparable  to  the  user’s  description.  The  system  also  provided  links  (i.e., 
"Relationships")  between  RSCs  so  that  the  user  can  browse  or  extract  related 
components. 

RAPID  maintained  RSC  metrics  on  reusability,  maintainability,  reliability, 
portability,  actual  usage,  and  outstanding  problem  reports.  Based  on  these  metrics,  the 
users  could  choose  to  rank  components  and  select  the  most  appropriate  ones. 


e.  Supporting  the  User 

User  support  and  feedback  is  an  essential  aspect  of  clearinghouse  activities.  In 
addition  to  the  assistance  from  its  central  office,  RAPED  offered  a  remote  site  program 
where  its  personnel  spend  a  period  of  time  at  the  user’s  site  to  assist  in  establishing  a 
local  reuse  repository  infrastructure  (e.g.,  reuse  planning,  hardware  and  software 
selection,  RSC  creation  and  population). 

Formal  training  was  also  part  of  RAPID’s  support  of  the  users.  Programs  have 
been  developed  at  three  levels;  Executive,  Management  and  Software  Engineering.  This 
training  is  available  at  both  the  Army  Reuse  Center  and  remote  sites. 

The  RAPED  librarian  solicited  the  RSC  recipient’s  feedback,  approximately  ninety 
days  after  the  RSC  extraction.  The  inquiry  was  intended  to  check  whether  or  not  the 
RSC  was  used  or  if  any  problem  was  encountered.  The  expectation  was  that  such  user 
feedback  provided  on  a  continuous  basis  would  ultimately  result  in  a  more  responsive 
library.  Furthermore,  this  feedback  would  provide  some  clues  in  assessing  the 
effectiveness  as  well  as  the  costs  of  reuse. 
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C.  DSRS  —  Toward  a  the  DoD-wide  Reuse  Program 


The  DoD  surveyed  software  reuse  efforts  within  the  department  and  keyed  on  the 
Army’s  RAPID  (Reusable  Ada  Products  for  Information  System  Development)  initiative. 
It  was  clear  that  this  program,  though  still  in  its  early  stages  of  development,  was  built 
upon  a  methodology  that  closely  aligned  with  DoD’s  vision  for  the  future  regarding 
reuse,  and  its  role  in  software  development.  Tapping  on  this  positive  learning 
experience,  DoD  established  in  1991  the  Defense  Software  Repository  Service  (DSRS). 


1 .  The  DoD  Reuse  Organizational  Structure 

As  described  in  Figure  1 ,  DSRS  is  under  the  management  and  supervision  of  the 
Center  for  Software  Reuse  Operations  (CSRO).  CSRO  is  a  component  of  the  Defense 
Information  Systems  Agency  (DISA).  DSRS  is  a  distributed  operation  with  four  remote 
centers  supporting  DoD  e  /ices  and  the  Defense  Logistics  Agency.22  DSRS  supports 
reuse  efforts  at  reir  Ac  centers,  and  ensures  that  these  efforts  are  complementary  and  not 
duplicative.  Predominantly  staffed  by  contractor  employees,  7  contract  personnel  fill 
billets  in  project  management  (1),  engineering  (4),  configuration  management  (1),  and 
librarian  (1).  Government  personnel  fill  positions  in  customer  service  (1)  and  liaison 
with  other  government  sites  (1). 

2.  Current  Status  of  the  DSRS  Effort 

DSRS  has  adopted  as  its  core  not  only  RAPID’s  library  of  RSCs  (at  the  time 
about  840  components),  but  its  infrastructure  as  well  (i.e. ,  classification/retrieval  system, 
RSC  certification  methodology,  etc.).  A.  the  same  time,  DSRS  also  accepted  RSCs  from 
previously  established  Navy  and  Air  Force  repositories.  To  date,  DSRS  more  than  1550 


22  The  reuse  remote  centers  are  located  at  the  following  sites:  Army  Reuse  Center  is  located  in  the 
Information  Systems  Command,  Falls  Church,  VA;  Navy  Reuse  Center  at  the  Naval  Computers  and 
Telecommunications  Station,  Washington  Navy  Yard,  D.C.;  Air  Force  Reuse  Center  at  the  Standard 
Systems  Center  at  Gunter  Air  Force  Base,  Ala.;  Marine  Corps  Reuse  Center  at  the  Development  Center, 
Quantico,  Va. 


CIM  Reuse  Organization 


On  site  Reuse  Support 


Fig  1:  CIM  Reuse  Organization 


components  comprising  over  two  million  lines  of  code.  RSCs  are  composed  of 
communications  packages,  graphics  programs,  man-machine  interfaces,  Ada  bindings, 
data  structures,  and  Ada  development  tools. 

DSRS  operates  on  a  MicroVax  4000-300  running  VMS  operating  system.23 
Users  can  access  DSRS  from  a  terminal  with  VT100  emulation  through  dial-up  modem 
or  via  the  Defense  Data  Network  (DDN),  although  full  networking  capability  via  DDN 
is  not  expected  until  January  1993.  Currently,  when  a  user  searches  for  an  RSC,  he  has 
to  access  not  only  the  DSRS  central  repository  but  also  the  ones  located  at  the  services. 
It  is  planned  that  all  repositories  will  be  interconnected  to  form  an  integrated  DSRS 
repository  by  the  end  of  1993. 

23  The  DSRS  hardware  platform  is  an  upgrade  of  the  RAPID  configuration. 
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CSRO  seeks  to  improve  the  user-friendliness  of  the  DSRS  interface.  Currently, 
on-line  help  is  made  available  to  familiarize  the  user  with  the  system.  DSRS  also  has 
a  feature  called  "Session  Maintenance"  that  allows  the  users  to  keep  track  of  his/her 
interaction  with  the  repository  system.  A  graphical  user  interface  is  being  studied  to 
replace  the  character-based  and  menu-driven  interface.  Finally,  CSRO  puts  in  place  a 
Customer  Assistance  Office  (CAO)  to  support  users. 
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V.  Lessons  Learned 


A.  A  Clearinghouse  is  a  Necessary  Condition  for  Software  Reuse  in 
DoD 

DSRS  has  been  established  to  respond  to  a  widely  recognized  need  for  a  centralize 
repository  of  reusable  components  in  DoD.  Given  that  donors  and  recipients  are 
separated  by  organizational  and  geographical  boundaries,  there  must  be  a  marketplace 
to  facilitate  the  exchange  of  RSCs.  A  DoD  clearinghouse  that  allows  networking  of  all 
of  its  remote  sites  is  expected  to  further  enhance  RSC  usability.  As  such,  a 
clearinghouse  contributes  to  the  proliferation  of  software  reuse.  Without  a  clearinghouse 
bridging  the  gap  between  RSC  donors  and  recipients,  the  software  reuse  effort  would  fall 
apart. 


B.  A  Clearinghouse  is  a  Productivity  Multiplier 

Early  signs  of  success  can  already  be  observed,  as  evidenced  by  the 
implementation  of  the  Retired  Army  Personnel  System  (RAPS)  and  the  Air  Force 
Logistics  Material  Automated  Retrieval  System  II  (LOGMARS). 

The  Retired  Army  Personnel  System  (RAPS)  is  a  report  generator  system  that  was 
a  pilot  study  by  developers  and  the  Army  Reuse  Center.  The  goal  from  a  reuse 
standpoint,  was  to  integrate  reusable  software  components  into  the  systems  development 
life-cycle  and  create  a  reusable  system.  Although  the  lines  of  code  (LOC)  in  RAPS  are 
not  substantial,  the  fact  is  that  reusable  modules  accounted  for  a  significant  percentage. 
Also  of  significance  is  the  use  of  design  components  as  well  as  implementation  RSCs: 

•  In  the  design  phase  four  of  ten  system  components  were  reused. 

•  Implementation  activity  involved  the  reuse  of  88  of  130  subunits.  This  accounted 
for  63.9%  of  LOC  dedicated  to  implementation. 


29 


•  Reuse  of  the  testing  packages  for  reused  modules  was  also  employed. 

The  time  savings  calculated  as  a  result  of  reuse  in  RAPS  development  amounted  to  more 
than  125  days. 

Similar  success  was  obtained  by  the  Air  Force  with  its  LOGMARS-H: 

•  Released  worldwide  in  February  92,  LOGMARS-H  is  a  PC-based  inventory 
control  system  used  in  supply  warehouses.  The  system  consists  of  18,600  lines 
of  Ada  code,  of  which  5,600  LOC  were  extracted  from  DSRS.  An  additional 
6,300  LOC  came  from  existing  in-house  modules. 

•  Also  developed  was  a  bar-coded  label  printing  subsystem  used  for  warehouse 
material  and  benchstock.  Two  modules  consisting  of  over  2,500  LOC  (28%  of 
total  system  code)  were  extracted  from  DSRS.  Five  other  modules,  including 
those  for  screens  and  forms  generation,  were  reused  from  LOGMARS-H. 
Overall,  73%  of  the  subsystem  code  consisted  of  reused  code. 

As  the  utilization  of  the  clearinghouse’s  RSCs  has  started  to  show  signs  of 
success,  it  is  expected  that  more  RSCs  will  be  demanded  in  the  future.  With  a  well- 
populated  repository,  the  clearinghouse  would  serve  as  a  productivity  multiplier. 


C.  The  Clearinghouse  Must  Populate  its  Repository  with  Quality 
RSCs 

In  response  to  the  growing  appreciation  of  reuse,  RSCs  are  being  inducted  into 
the  repository  at  a  rapid  pace.  The  clearinghouse  must  ensure  that  RSC  quality  is  not 
compromised  in  the  process.  RSC  users  are  reluctant  to  utilize  components  of  uncertain 
quality  developed  by  unknown  sources.  They  would  accept  nothing  but  "error-free" 
RSCs.  The  clearinghouse  must  carefully  weigh  the  benefits  of  accelerating  the 
population  growth  of  RSCs,  against  the  potential  damage  that  might  be  caused  if  users 
experience  problems  with  RSCs. 


30 


D .  High-Level  DoD  Management  Must  Provide  Incentives  for  Reuse 


A  fully  functioning  repository  populated  with  pertinent  components  is  a  necessary 
but  not  sufficient  condition  to  promote  a  successful  reuse  program.  Some  inducement 
to  reuse  software  is  required  as  well.  To  carry  the  necessary  weight  and  visibility,  these 
incentives  must  be  promulgated  from  the  highest  authority  within  DoD. 

While  many  DoD  organizations24  involved  in  software  reuse  have  recognized  this 
issue,  there  is  no  policy  regarding  financial  incentives.  It  is  imperative  that  incentives 
research  continue  and  these  critical  issues  be  resolved  in  order  to  implement  a  competent 
reuse  strategy. 


24  CSRO  recognizes  the  critical  issue  of  reward,  and  is  working  closely  with  organizations  such  as 
the  Joint  Avionics  Working  Group  (JIAWG),  and  the  Ada  Joint  User’s  Group  (AdaJUG)  both  of  which 
are  conducting  extensive  research  on  incentive  issues. 
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Glossary  of  Terms 


ADA  -  Programming  language  that  facilitates  reuse.  Ada  is  the  primary  programming 
language  in  the  Department  of  Defense. 

ADAMAT  -  A  static  source  code  analyzer  that  produces  150+  metrics  on  the  quality  of 
Ada  code  as  it  pertains  to  reliability,  maintainability,  and  portability. 

CASE  (Computer  Aided  Software  Engineering)  -  Collective  resource  to  a  family  of 
software  productivity  tools. 

CODE  REUSE  -  The  most  common  form  of  software  reuse  in  which  source  code  is 
reused. 

DESIGN  REUSE  -  Reuse  of  a  type  of  reusable  software  component  such  as  logical  data 
models,  functional  descriptions,  and  diagrams. 

DOMAIN  -  A  group  or  family  of  related  systems  that  share  a  set  of  common  capabilities 
and/or  data. 

DOMAIN  ANALYSIS  -  The  thorough  examination  of  a  domain  that  produces  a 
representation  of  the  domain  and  identifies  common  domain  characteristics,  primary 
functions,  and  objects. 

FACETED  CLASSIFICATION  SCHEME  -  Components  are  classified  by  selecting  the 
most  appropriate  terms  from  each  facet  to  best  describe  the  component. 

FOURTH  GENERATION  LANGUAGE  -  Programming  language  that  uses  high-level 
human-like  instructions  to  retrieve  and  format  data  for  inquiries  and  reports 

GRANULARITY  -  The  size  of  the  chunk  of  code. 

IMPLEMENTATION  REUSE  -  Reuse  of  a  type  of  reusable  software  component  such 
as  package  specifications,  package  bodies,  subsystems,  and  test  suites. 

METRICS  -  Numeric  measures  that  characterize  RSCs. 

OBJECT-ORIENTED  DESIGN  -  Method  for  generating  reusable  software  components. 
It  uses  data  types  as  the  base  for  modularization  and  defining  objects. 
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REPOSITORY  -  Storage  area  for  reusable  software  component. 

REUSABLE  SOFTWARE  COMPONENT  -  Originally  a  source  code  component 
consisting  of  functions,  procedures,  or  packages.  Now  it  includes  requirements,  design, 
implementation,  templates,  and  generic  architectures. 

REUSABILITY  -  Ability  for  a  software  component  to  be  reused. 
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